Service oriented architecture (SOA) is a business-driven IT architectural approach that supports integrating the business as linked, repeatable business tasks, or services. The basic building block is a service document that defines a service so that it can be managed with other services. A service document contains information about a service including the location of the service and details about the service and how to access the service. Service documents are used by analysts, architects, and developers during a Development Phase of the SOA life cycle to locate services to reuse and to evaluate the impact of changes to service configurations. Service documents are variously described as metadata, objects, descriptions, entities and artifacts.
A service repository stores the service document and allows access to the service document and thereby the corresponding service. A service registry is an index of a subset of information about a service (for example the location and name of service document) enabling the corresponding service document to be located and accessed in a repository (or even the corresponding service located at the service provider). An integrated service registry and repository allows a service operation to use both the indexed service information in the registry and the detailed service information in the repository. An example of an integrated service registry and repository is IBM® WebSphere® Registry and Repository (WSRR).
Such an integrated service registry and repository has advantages of greater business agility and resilience through reuse than separate systems. Further advantages of looser coupling, greater flexibility, better interoperability, and better governance arise from the integration. These advantages are addressed by separating service descriptions from their implementations, and using the service descriptions across the life cycle of the service. Standards-based service metadata artifacts, such as Web Service Definition Language (WSDL), extensible mark-up language (XML) schema, policy or Service Component Architecture (SCA) documents, capture the technical details of what a service can do, how it can be invoked, or what it expects other services to do. Semantic annotations and other metadata can be associated with these artifacts to offer insight to potential users of the service on how and when it can be used, and what purposes it serves.
A policy is a rule that is applied to an object by an environment. For instance, access to an object can be controlled by applying a rule that only entities with a certain token can have access to the object. W3C (World Wide Web Consortium) is a community working together to develop interoperable internet technology.
WS-Policy is a W3C WS (Web Service) standard that is intended to provide a means for specifying policies that need to be applied to Web Services and specifically service documents. The WS-Policy-Attach specification (also controlled by the W3C) specifies a standard means by which policy attachments can be defined to link a policy to a service object referenced in a service document. Service objects or logical objects are derived from documents (WSDL (Web Service Definition Language) documents; XSD (XML schema definition) documents; XML (extensible mark-up language) documents, WS-Policy documents etc.) when they are loaded into the Service Registry environment. The WS-Policy-Attach specification declares different means of specifying policy attachments that link specific policies to target subjects: embedded policies in WSDL documents; embedded policy references in WSDL documents; embedded policy references from policyURI (Universal Resource Indicator) attributes in WSDL documents; embedded policies in external policy attachment files; and embedded policy references in external policy attachment files.
A Policy can be a generic policy as defined in the WS-Policy Framework or it can be a domain specific policy as defined in a policy domain. If a policy is domain specific then it will specify the WSDL Elements to which it can be attached.
One problem when specifying policy attachments is the complexity of the semantics required to correctly specify the attachment. For instance an identifier for a policy can comprise two or more parts: a namespace; a WSDL element type; and actual element name. Another problem users face is an array of choices when it comes to attaching policies to subjects but no easy way of identifying the right subjects to attach the policies too. A further problem for a user that has found an element there is no easy way to see which policies can be attached to it. All these problems can quickly lead to the creation of either invalid or incorrect policy attachment documents.